Five small fixes from review of the ContentSource capability:

- pipeline/content.go (InferenceExtension.Fragments): switch from
  make([]Fragment, 0, cap) + "if len==0 return nil" dance to
  `var out []Fragment`. Matches the nil-when-empty idiom used by
  A2AExtension and MCPExtension; the cap hint isn't measurable on
  this path.

- pipeline/content.go (stringifyAny): log at DEBUG on json.Marshal
  error so the skip is observable in verbose runs rather than
  invisible. Tighten the docstring to call out the JSON-origin-data
  precondition for future callers whose values may not round-trip.

- pipeline/content.go (normalizeA2ARole): reword the comment about
  the "raw value" escape hatch. Consumers going through the
  ContentSource interface cannot reach *A2AExtension.Role without
  a type assertion back to the concrete type — the original
  wording overstated what's available to generic guardrails. New
  wording: A2A-aware consumers may type-assert; framework-generic
  guardrails treat the normalized value as authoritative.

- contracts/content.go (Fragment): add a forward-compat note on the
  struct recommending named-field initialization, so existing call
  sites and tests survive when fields are added (Path locator for
  violation citations, Kind hint for format-aware scanners).

- docs/plugin-tutorial.md (Step 8): half-sentence pointer to
  A2AExtension.Fragments as the role-normalization reference, so
  readers copy-pasting the minimal example know to remap native
  role vocabularies to contracts.Role* constants.

No behavior change. Tests still pass in authlib, cmd/authbridge,
and cmd/abctl under GOWORK=off; vet clean; gofmt clean.

Assisted-By: Claude (Anthropic AI) <noreply@anthropic.com>
Signed-off-by: Hai Huang <huang195@gmail.com>

Previous fixup (548bd10) reworded the normalizeA2ARole comment to
describe type-assertion as the escape hatch for reading "the raw
value." That framing was wrong: it accepted the premise that the
interface hides role information consumers need, when the actual
design is that Fragment.Role IS the role information, in a uniform
vocabulary across every protocol.

Rewrite the comment to state the intent directly:

- Normalization to the standard vocabulary is the design goal, not
  a compromise. A guardrail compares f.Role == contracts.RoleUser
  once and works across A2A, MCP, and Inference.
- Fragment.Role is authoritative — no type-assertion needed in the
  common case.
- Type-assertion to *A2AExtension.Role is only appropriate for
  A2A-specialized tooling that wants the wire-level native value
  ("agent") verbatim, e.g., a protocol inspector. Framework-generic
  consumers should not do that.

No behavior change.

Assisted-By: Claude (Anthropic AI) <noreply@anthropic.com>
Signed-off-by: Hai Huang <huang195@gmail.com>

Add a forward-reference paragraph to normalizeA2ARole explaining why
this helper (and the corresponding Fragments methods on A2AExtension,
MCPExtension, InferenceExtension) lives in pipeline/content.go rather
than alongside its parser in plugins/.

Short version: Go requires methods on a type to be declared in the
type's own package, and the extension types currently live in
pipeline/ as named slots on Extensions. A planned protocols-registry
refactor will move the extension types into their parser packages
(removing the named slots); at that point the methods and helpers
move with them. Until then, the logical misplacement is marked in
the code so a future reader understands it's a known shape, not an
accident.

No behavior change.

Assisted-By: Claude (Anthropic AI) <noreply@anthropic.com>
Signed-off-by: Hai Huang <huang195@gmail.com>

PR rossoctl#393 review raised two concerns about MCPExtension.Fragments:

1. Silent type-assertion skips hide malformed (potentially malicious)
   non-conforming MCP payloads. A client that sends something other
   than a map for Params["arguments"] or an array for Result["content"]
   gets skipped with no signal anywhere.

2. JSON-RPC-level errors carry a Message field that may contain
   inspectable content (leaked credentials in "invalid url: ...",
   stack traces, PII from failed DB lookups). Today guardrails
   never see it — the error channel is a gap in coverage.

Changes:

- Log at DEBUG on each unexpected-shape skip inside MCPExtension.Fragments:
  * Params["arguments"] present but not map[string]any
  * Result["content"] present but not []any
  * Result.content[i] present but not map[string]any
  Full counter/metric wiring would be heavier than the concern warrants;
  a DEBUG log is the right level for "operator debugging a weird client."

- Emit MCPError.Message as a role=tool_result fragment when Err is
  non-nil and Message is non-empty. A PII scrubber, credential
  detector, or content classifier now covers the error channel
  uniformly with normal tool output.

Also updates the MCP row in plugin-reference.md's role-mapping table
to note the tool_result role now covers both result text AND error
messages.

Tests: 5 new cases covering error-only, error-plus-result,
empty-error-skip, malformed-arguments-skip, and malformed-result-skip.

No behavior change for well-formed MCP traffic.

Assisted-By: Claude (Anthropic AI) <noreply@anthropic.com>
Signed-off-by: Hai Huang <huang195@gmail.com>